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A Uniform Resource Name Namespace for 
the EPCglobal Electronic Product Code (EPC) and Related Standards 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document describes URN namespaces that will identify various 
objects within the EPCglobal system for identifying products within 
ecommerce and supply chain management applications. 


1. Introduction 


The EPCglobal Architecture Framework [6] is a set of specifications 
for reading, managing, and acting on object codes and other sensor 
data as physical objects pass through a supply chain. Events and 
metadata about physical objects are exchanged via EPCglobal 
Electronic Product Code Information Services (EPCIS) that are 
essentially web services that implement agreed upon schema and 
interfaces. 


Each object that is tracked by the EPCglobal Architecture Framework 
is identified by one or more managed identifiers. In many cases, 
these identification systems existed prior to the Internet becoming 
widely used. One such namespace is the Global Trade Item Number, or 
GTIN [7]. GTINs are widely used in global commerce and are managed 
by GS1. In order for the EPCglobal Architecture Framework to 
leverage the Internet to the fullest extent possible, the GTIN 
namespace (and others, such as Global Location Numbers (GLNs), 
Serialized Shipping Container Code (SSCC), etc. [7]) need to be 
directly compatible with the URI family of identifiers. 


The use of GTINs, GLNs, and SSCCs are all managed by GS1. Their use 
within the EPCglobal Architecture Framework is managed by the GS1 
subsidiary known as EPCglobal, Inc. For these, and possibly future 
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identification systems, a single Uniform Resource Name (URN) 
Namespace ID (NID) is being requested: ’epc’. Each of the identifier 
namespaces mentioned will have a separate sub-space beneath the top 
level ’epc’ NID. 


In addition to physical object identifiers, the EPCglobal 
Architecture Framework requires new namespaces for naming system 
components. In many cases, an interface within the EPCglobal 
Architecture Framework is XML [11] based and as such will require 
naming schemes for its XML schema [9] and various namespaces [10]. 
For these uses, another Uniform Resource Name (URN) Namespace ID 
(NID) is being requested: ’epcglobal’. Each specification or system 
component within the EPCglobal Architecture Framework will have a 
separate sub-space beneath the top level ’epcglobal’ NID. 


Since the EPCglobal Architecture Framework is engineered for 
widespread and general use, this namespace specification is a formal 
one, and the namespace IDs that are being requested are ’epc’ and 
‘epcglobal’. It is important to note that it is the explicit intent 
that various sub-namespaces of the ’epc’ NID actually name real, 
physical objects and/or corporeal entities. In contrast, sub- 
namespaces of the ’epcglobal’ NID name logical or software 
constructs, such as schema namespaces. 


2. ‘epc’ Registration Template 
Namespace ID: 
" epc " 
Registration Information: 


Registration Version Number: 1 
Registration Date: 2008-01-16 


Declared registrant of the namespace: 


EPCglobal, Inc. is a subsidiary of GS1 
Princeton Pike Corporate Center 

1009 Lenox Drive, Suite 202 
Lawrenceville, NJ 08648, USA 
bhogan@epcglobalinc.org 

Tel: +1-609-620-4585 
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Declaration of structure: 


The normative specification of the structure of the ’epc’ 
namespace is "EPC Tag Data Standards" [5]. The examples given 
below are not normative. 


The ’epc’ namespace is a set of sub-namespaces that can be 
extended in the future. The following ABNF [2] defines how the 
sub-namespaces are identified and any restrictions on their 
syntax (definitions not specified below can be found in RFC 


2141 [1]): 
EPC-URN = "urn:epc:" sub-ns-name ":" sub-ns 
sub-ns-name = let-num [ 1*let-num-hyp ] 
sub-ns = 1*<URN chars> 
let-num = upper / lower / number 
let-num-hyp = upper / lower / number / "-" 
upper = %x41-5A ; "A" - "Z" 
lower = $x61-7A ; "a™ e eT 
number = "on / "q" / wow / "3m / wan / wow / wen / "7" / 


von f. wou 


For example, the sub-namespace ’sgtin’ has the following 
definition (this ABNF is non-normative): 


SGTIN-URI = "urn:epc:id:sgtin:" SGTINURIBody 

SGTINURIBody = 2* (PaddedNumericComponent ".") NumericComponent 
NumericComponent = ZeroComponent / NonZeroComponent 

ZeroComponent = "o" 

NonZeroComponent = NonZeroDigit *Digit 

PaddedNumericComponent = *Digit 

Digit = "0" / NonZeroDigit 

NonZeroDigit = "0" / wow / wou / wan / wow / wen / "7" / wow / won 


This equates to a namespace that has three period separated series of 
digits: 


urn:epc:id:sgtin:900100.0003456.1234567 


The first series is a company prefix, the second denotes a product 
reference assigned by that company, and the third is a serial number 
for a specific instance of their product. Note that leading zeros 
are significant. 
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Relevant ancillary documentation: 


The standards that define the EPCglobal Architecture Framework 
and the processes for creating new sub-namespaces are managed 
by EPCglobal, Inc. and can be found on its website. Several 
sub-namespaces are defined in the "EPC Tag Data Standards" [5]. 


Identifier uniqueness considerations: 


The namespaces that make up the ’epc’ namespace are all managed 
by an organization with almost 50 years of namespace management 
experience. In all cases (existing or new), the uniqueness of 
each namespace is an inherent part of the EPCglobal 
Architecture Framework. 


Identifier persistence considerations: 


The assignment process guarantees that names are not reassigned 
and that the binding between the name and its resource is 
permanent, regardless of any standards or organizational 
changes. 


Process of identifier assignment: 
Names are assigned by the EPCglobal standards publication 
process and by any entities that are sub-delegated by 
EPCglobal. It is important to note that in many cases the 
names assigned will explicitly denote physical objects and not 
an electronic representation of that object. 

Process of identifier resolution: 
Certain sub-namespaces are resolved via the Object Naming 
Service, defined in "Object Naming Service (ONS) Version 1.0" 
[4], which is a valid implementation of the Dynamic Delegation 
Discovery System that is defined in RFC 3401 [3]. 

Rules for Lexical Equivalence: 
The entire URN is case-sensitive. 


Conformance with URN Syntax: 


There are no additional characters reserved except as noted in 
the ABNF above. 
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Validation mechanism: 


In the case of each sub-namespace, there will be namespace- 


specific rules for determining validity. In each case, the 
reader is referred to the appropriate EPCglobal-maintained 
documentation. 

Scope: 
Global 


3. ‘'epcglobal’ Registration Template 
Namespace ID: 
"epcglobal" 
Registration Information: 


Registration Version Number: 1 
Registration Date: 2007-03-06 


Declared registrant of the namespace: 


EPCglobal, Inc. is a subsidiary of GS1 
Princeton Pike Corporate Center 

1009 Lenox Drive, Suite 202 
Lawrenceville, NJ 08648, USA 
bhogan@epcglobalinc.org 

Tel: +1-609-620-4585 


Declaration of structure: 


The normative specifications for the structure of the 
‘epcglobal’ namespace are various standards available at 
EPCglobal’s public website. The examples given below are not 
normative. 


The ’epcglobal’ namespace is a set of sub-namespaces that can 
be extended in the future. The following ABNF defines how the 
sub-namespaces are identified and any restrictions on their 
syntax (definitions not specified below can be found in RFC 
2141 [1].)% 


Mealling Informational [Page 5] 


Mealling 


RFC 5134 The EPC URN January 2008 
EPCGLOBAL-URN = "urn:epcglobal:" subnsname ":" subns 
subnsname = let-num [ 1*let-num-hyp ] 
subns = 1*<URN chars> 
let-num = upper / lower / number 
let-num-hyp = upper / lower / number / "-" 
upper = %x41-5A ; "A" MA 
lower SOROLTA; y aTM 
number = "on / "q" / wow / wou / "g" / wow / wen / "7" / 
non / mon 


For example, the identifier "urn:epcglobal:ale:xsd:1" is defined in 
the "Application Level Events 1.0 Specification" [8] for use as an 
XML namespace identifier for XML documents conforming to that 
specification. 


Relevant ancillary documentation: 


The standards that define the EPCglobal Architecture Framework 
and the processes for creating new sub-namespaces are managed 
by EPCglobal, Inc. and can be found on its website. 


Identifier uniqueness considerations: 


The namespaces that make up the ’epcglobal’ namespace are all 
managed by an organization with almost 50 years of namespace 
management experience. In all cases, the uniqueness of each 
namespace is an inherent part of the EPCglobal Architecture 
Framework. 


Identifier persistence considerations: 


The assignment process guarantees that names are not reassigned 
and that the binding between the name and its resource is 
permanent, regardless of any standards or organizational 
changes. 


Process of identifier assignment: 


Names are assigned by the EPCglobal, 
process. 


Inc. standards publication 


Process of identifier resolution: 


No resolution mechanism is required or provided. 
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Rules for Lexical Equivalence: 
The entire URN is case-sensitive. 
Conformance with URN Syntax: 


There are no additional characters reserved except as noted in 
the ABNF above. 


Validation mechanism: 


In the case of each sub-namespace, there will be namespace- 


specific rules for determining validity. In each case, the 
reader is referred to the appropriate EPCglobal-maintained 
documentation. 

Scope: 
Global 


4. IANA Considerations 


This document includes two URN Namespace registrations that have been 
entered into the IANA registry for URN NIDs. 


5. Namespace Considerations 


Due to EPCglobal, Inc. being a subsidiary of an internationally 
recognized authority for the identifiers embedded within the ’epc’ 
namespace, as well as being the internationally recognized standards 
body for the standards that define identifiers in the ’epcglobal’ 
namespace, these namespaces represent the best approach to naming 
products and entities within the world of supply chain management and 


ecommerce in general. There are no other alternative namespaces that 
have the level of authority and industry acceptance that the EPC 
does. 


6. Community Considerations 


The EPCglobal Architecture Framework is intended to bring the 
Internet to the world of supply chain management and beyond. It can 
be used to tie physical objects to their virtual descriptions and as 
such has many wide ranging applications for the average Internet use. 
Thus, it is very much the intent that this namespace, and the entire 
EPCglobal Architecture Framework, considers the entire Internet as 
the scope of its community. 
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7. Security Considerations 


The EPCglobal Architecture Framework is based almost exclusively on 
Internet and Web standards. Thus, the security impacts of each of 
its underlying technologies should be examined for weaknesses and 
threats. The primary threats will come from the fact that these 
names will identify physical things that can be of high value, thus 
the temptation to spoof metadata about that identifier (its cost, 
size, etc) will be much greater. Therefore, the role of digital 
signatures, secure resolution mechanisms, and trust relationships is 
very fundamental to the system. 
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Intellectual Property 
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this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
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on the procedures with respect to rights in RFC documents can be 
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